Databases offer various transaction types to provide data consistency for concurrent data access by multiple processes. The strongest transaction types in widespread use provide the following well-known “ACID” properties to describe the impact of one transaction T: atomicity, consistency, isolation, and durability. The property of atomicity requires that, if T takes multiple actions, the end result is either that they all happen, or that none of them happen. The property of consistency requires that, if the database is in a consistent state when T begins, it will be in a consistent state when T ends. The property of isolation requires that other transactions see either none, or all, of T's actions. In other words, each transaction operates as if it were the only client accessing the system, even though in reality this is not the case. The property of durability requires that T's actions, once committed, remain in effect despite system failures.
However, it is difficult to provide these guarantees in a large scale, replicated, distributed database. Typical mechanisms for providing the ACID properties include a log manager and a lock manager. However, a scalable lock manager is difficult to implement in a large scale distributed database that is replicated. For example, database systems usually provide transactional consistency by ensuring serializability of semantic operations on data in a distributed database. In general, each machine in a distributed database system may request and obtain locks to data records and indexes to those records while the data is updated. Once the data and the indexes are updated, the locks may be released. Although this approach may provide strong consistency of data in primary data tables and indexes in a replicated distributed database system, these operations are expensive to execute and impedes scalability. Similarly, a distributed consensus protocol such as two-phase-commit may be implemented but this operation is also expensive to execute. It is for these reasons that typical distributed databases such as Oracle RAC and DB2 often scale to only tens or maybe hundreds of servers.
In order to scale to thousands of servers, a weak consistency model may be used. Unfortunately weak consistency models typically provide isolation guarantees for the simplest of transaction types that just read and write a single record. Often applications want to execute atomic, consistent, isolated and durable transactions that touch multiple records. Thus, weak consistency models fail to provide isolation guarantees for transactions that may include multiple records.
What is needed is a way to implement consistency guarantees for database transactions that read multiple records to achieve serializability and scalability.